home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group99a.txt / 000044_icon-group-sender _Mon Mar 1 09:00:53 1999.msg < prev    next >
Internet Message Format  |  2000-09-20  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA28134
  4.     for icon-group-addresses; Mon, 1 Mar 1999 08:57:45 -0700 (MST)
  5. Message-Id: <199903011557.IAA28134@baskerville.CS.Arizona.EDU>
  6. To: icon-group@optima.CS.Arizona.EDU
  7. Date: Sat, 27 Feb 1999 04:23:00 GMT
  8. From: eodell@pobox.com (Eric O'Dell)
  9. Subject: Re: Bridging Icon and C Calls
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12.  
  13. On 23 Feb 1999 16:55:50 -0500, "Frank Lhota"
  14. <lhotaf@lexma.meitech.com> wrote:
  15.  
  16. >I have some ideas about how this facility could be designed, and
  17. >implemented. Before proceeding this much further, however, I would like some
  18. >feedback. Would other Icon programmers find this useful?
  19.  
  20. I think this would be enormously useful even if it wasn't portable
  21. from platform to platform. Being able to code speed-critical sections
  22. in C, or just to use pre-existing C functions would be a godsend. If
  23. it _was_ portable from one platform to another, it would be even more
  24. useful. I'm all for it.
  25.  
  26. -E.
  27.  
  28.  
  29.  
  30.  
  31. +-------------------------------------------------------------------+
  32. | "I have come a very long way from myself only to realize that     |
  33. | identity is a skill and self-betrayal is a habit. Once lost, the  |
  34. | former is very hard to regain; once gained, the latter is very    |
  35. | hard to lose."  ---I. Corvus, _The Europe of Our Dreams_          |
  36. +-------------------------------------------------------------------+
  37.